feat: converge template identity, runtime contracts, and release state - #400
Conversation
|
Checkpoint — exact local-index namespace inheritance (
Next checkpoint will migrate the affected E2E fixtures and validate the previously failing local-index scenarios against this commit. |
|
Checkpoint — exact identity retained through the build resolver ( The first fix covered shared Evidence:
|
|
Checkpoint — ELF loader physics / multi-glibc correctness ( The closure validator was resolving every dependency's This commit now:
Verification:
|
|
Validation checkpoint — local-index exact identity group Against current Draft-PR HEAD
These use isolated fresh sandboxes and the rebuilt PR CLI. No test fixtures needed loosening: the implementation fixes make their existing exact selectors resolve as intended. |
|
Checkpoint — E2E contract migrations ( Three tests were asserting pre-exact-identity or host-capability behavior rather than product regressions:
Local verification with the rebuilt PR CLI: 3/3 passed (100, 123, 204). Diff/privacy checks passed. |
|
Checkpoint — fake xlings fixtures retain truthful SubOS contracts ( E2E 52 and 58 used a fake The fixtures now copy the already inherited native runner's default SubOS contract into the fake home. This keeps the fake focused on install ordering/index transport while preserving truthful platform/runtime facts. Verification: 52 and 58 pass 2/2 with the rebuilt PR CLI. Diff/privacy checks passed; the committed tests contain no host-specific contract or path. |
|
Checkpoint — exact misses retain an unreadable-index cause ( The exact-selector failure path bypassed the existing E2E 185 is green across all three gates:
Diff/privacy checks passed. |
隐私身份 checkpoint已由 问题与根因:完整 PR added-line/privacy 复核发现,AUR reconciler 的提交身份仍硬编码了个人邮箱; RED:新增 public service identity contract 后,测试因 GREEN:
本 commit 和 push 本身也使用 |
文档一致性 checkpoint已由 同步内容:
|
Checkpoint:精确索引路由诊断(
|
Checkpoint:交接与验证账本同步(
|
Draft PR 正文已同步已把 |
中文任务交接(最新单入口)当前交接对象:Draft PR #400,分支 HEAD 完整交接文档: 已做
遇到的问题与当前判断
已有验证
还没有做
接手顺序
强制边界
|
The Windows E2E 2/2 failure is not the workspace index inheritance the
last three commits were aimed at. It is step (15) of 12_add_command.sh,
added by this branch, which writes an MSYS path into a manifest:
TMP=$(mktemp -d) # Git Bash -> /tmp/tmp.XXXXXXXX
acme = { path = "$TMP/myapp/index" } # written as FILE CONTENT
MSYS converts POSIX paths on the way into argv and the environment; it
does not convert file content. A native mcpp.exe reads the literal
leading `/` as "root of the current drive", so the fixture index
resolves to C:\tmp\... and is absent. That is exactly what the route
diagnostic reported: `local index 'acme': root absent, pkgs absent`.
Four independent signals place the failure at step (15), not (14):
exit code 2 is mcpp's own status forwarded by `set -e`, while step (14)
is wrapped in `|| { …; exit 1; }`; step (14)'s failure banner never
appears; the last uncaptured output before it belongs to step (12); and
step (14) predates this branch, on which the Windows suite was green.
The Wine replay that "reproduced it as passing" was a false negative:
Wine maps Z: to /, so \tmp\... lands back on the real /tmp. Wine can
show a PE runs. It cannot show anything about path semantics.
Fixed as a class rather than a line. `_host_path.sh` provides
`host_path` (cygpath -m on MSYS, identity elsewhere, relative paths
untouched), 00_fixture_path_hygiene.sh fails any fixture that
interpolates a non-`*_HOST` variable into a TOML `path =` value, and the
40 pre-existing sites across 24 files are migrated. Most were masked
only because those tests skip on Windows for a missing capability.
`inherit_workspace_indices` was switched from `weakly_canonical` to `lexically_normal` in ed4cf64 to fix the red Windows suite. It did not: the same failure appeared identically before (run 31318089536) and after (run 31321961040), and the actual cause was a fixture writing an MSYS path into mcpp.toml. So the change was landed against a misdiagnosis, against a behaviour that was green on main, with no test able to tell the two spellings apart. It turns out to be right for a different reason, and now it says so. Anchoring answers "which directory did the workspace author mean", and the answer must stay inside the tree the author addressed. `weakly_canonical` answers "what is this path once every symlink is resolved", so a workspace reached through a symlinked parent gets relocated into a tree the author never wrote — observable, because prepare reports a missing descriptor as "not found in local index at '<path>'". Verified as a real RED: restoring `weakly_canonical` fails `unit/test_pm_index_route` (71 passed, 1 failed). The existing test also stops asserting a path SPELLING. Comparing the stored path against `(root / "index").lexically_normal()` passes for any rule that happens to produce that string and says nothing about whether the index can be read — which is how it stayed green through a red Windows suite. It now asserts the capability: route description, then a descriptor lookup that actually resolves.
Namespace omission means exactly `mcpplibs`. But every published `compat.*` package and every manifest written before exact identity spells its dependency bare — `gtest = "1.15.2"`, `ftxui = "6.1.9"` — so turning that into an immediate hard error makes an mcpp upgrade break builds against data that is already published and cannot be edited retroactively. Four CI jobs on this branch are that breakage, and this repository's own mcpp.toml had to move gtest under [dev-dependencies.compat] to keep bootstrapping: a change that breaks its own project is breaking everyone's. It is the mirror of the rule that keeps a raised index floor from bricking older clients. Published data must not break the program; a published program must not break existing data either. Both degrade. The #278 defect was the SILENCE, not the reach: mcpp continued with a namespace the user never wrote and never said so. So the rungs come back, and cannot be quiet. After the exact coordinate misses, and only for a selector whose namespace was OMITTED, `(compat, name)` and the namespace-less discovery rung are tried; a hit is announced with the canonical selector and the exact manifest edit, and the canonical identity — not the ambiguous spelling — is what reaches the lock, the install layer and the cache label. `mcpp add` goes further and performs the edit, so touching a dependency migrates it. `mcpplibs.gtest` states an identity and still misses. A third-party namespace is still unreachable by a bare name. Removed in 2026.9, named once as kBareNameFallbackRemovedIn so the warning, the docs and the removal cannot drift apart. Test 162 now asserts both branches and that an already-exact selector is not nagged, and it serves the compat fixture from its own index instead of whatever gtest happened to be installed.
) `mcpp run` put the private glibc directory on LD_LIBRARY_PATH. That variable is inherited by every process the program ever spawns, and a child like /bin/sh is loaded by the HOST loader — PT_INTERP is baked in and no environment variable overrides it. glibc's libc.so.6 and its ld.so are version-locked through GLIBC_PRIVATE, so the child dies during relocation, before main: sh: symbol lookup error: …/xim-x-glibc/2.44/lib64/libc.so.6: undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE The reporter hit it through an application probing the desktop theme with gsettings: popen() returned nothing, the app silently used the wrong theme, and mcpp said nothing. Verified locally — the 2.44 payload kills /bin/sh, the 2.39 payload does not, which is why this survived as long as it did and why "it works here" proved nothing. The directory was published to serve a dlopen() the executable's DT_NEEDED closure does not cover, and the artifact's RUNPATH already covers exactly that: the link model emits -Wl,-rpath,<glibc> next to --dynamic-linker, and the built binary's RUNPATH is byte-identical before and after this change. So the environment entry bought nothing and cost every child process. It is gone. Measured against the released mcpp with the same fixture: before LDLP=[…/runtime:…/xim-x-glibc/2.39/lib64] after LDLP=[…/runtime] The decision lives in mcpp.platform.runtime_env_contract as a scope, not a condition: no build-level predicate can make an inherited variable safe for a process mcpp did not launch and cannot see. mcpp#291 was the same mistake one hop closer in. 208 pins all three halves — the dir is in the artifact RUNPATH, it is not in the program's environment, and both the /bin/sh child and the dlopen still work. The RUNPATH assertion deliberately checks coverage mcpp does not itself emit, so losing it is a red test rather than a silent loss of resolution.
The Linux closure verdict is cached against the artifact stat and the RuntimeBinding contract hash, and caching a FAILURE is the half worth pinning: an unchanged artifact that was proven wrong is still wrong, and reporting success the second time tells the user a problem went away when nothing about the program changed. It is easy to lose by accident, because the project fast path exists to skip work when nothing changed — including, unless something stops it, the check that would have failed. `validated_artifact_snapshot` stops it by refusing to engage unless every stored verdict is a PASS; that rule had no test. 209 poisons one stored verdict without touching a source file and requires the next build to fail with the recorded diagnostics, requires `mcpp self doctor` to explain it from storage, and then requires a rebuilt artifact to be re-validated — a mismatch is cached, not a sentence, or the first real failure would wedge the project until someone deleted target/.
`schedule` fires every six hours off the default branch and set publish=true unconditionally. Merging this workflow was therefore enough to make mcpp start writing to the AUR on its own, within six hours, on a path that had never completed a real push — only a makepkg --verifysource dry-run. Merging is a decision about code; publishing to a third-party service is a decision about the outside world, and they should not be the same act. Both automatic triggers now plan and report but withhold the push unless the repository variable AUR_AUTOPUBLISH is exactly "true", so a typo fails closed. Dry runs still validate payloads, render .SRCINFO, query the AUR and print the diff — only the push is withheld, so nothing is lost but the surprise. workflow_dispatch keeps its explicit per-run switch, which is how the first watched publish is meant to happen, and unsetting the variable is a kill switch that needs no revert. The contract test runs the workflow's own decision shell rather than a paraphrase of it, so the guarantee cannot drift from the YAML.
Every test covering local-index addressing needed `gcc` or `fresh-sandbox`, and Windows has neither capability. So the one platform where path semantics actually differ was the one platform never asserting them — which is why a fixture could write an MSYS path into mcpp.toml and the failure surfaced four steps away, as "package not found in any configured index", and was chased through the workspace inheritance code that was not involved. 210 needs no compiler, no sandbox bootstrap and no network: it asserts at the resolution layer, which is the layer that was broken. An absolute [indices] path resolves; a workspace member inherits a root-relative one and reads it; a miss in both reports the index as a READABLE root, since "root absent" is the fingerprint of a path written in the wrong spelling; and the route diagnostic that makes any of this findable stays free of filesystem paths.
Two independent bumps that happen to land on the same date string. The xlings pin moves from 2026.8.9.2 to the current stable 2026.8.10.1 across all 16 pin sites; check_version_pins.sh verifies them against src/xlings.cppm rather than trusting a comment. Note that 2026.8.10.1 still declares a bare `ftxui`, so the four cross-repo CI failures on this branch are resolved by the bare-name migration window in this PR, not by the pin — openxlings/xlings#521 remains the correct upstream fix and is no longer on the critical path. The release version moves from 2026.8.9.1 to 2026.8.10.1 because the version is a DATE and the date changed while this branch was in review. 2026.8.9.1 was never tagged, so nothing depends on the old string. The release-manifest and AUR fixtures derive "some other version" from VERSION; both halves move so they stay distinct instead of collapsing onto the release version and silently asserting nothing. Bootstrap pin stays at the released 2026.8.8.4 — it is the self-hosting starting point, not a function of what this release will be.
Three things a user or a maintainer cannot discover from the code: - The one-release exit ramp for namespace-omitted selectors: what still resolves, what the warning says, that the canonical identity is what reaches the lock, that `mcpp add` performs the migration, and that a stated namespace is not eligible. Written with the reason attached — every published `compat.*` package spells its dependency bare, so failing them outright would make a program release invalidate data that is already published and cannot be edited. - Why the private libc directory is binary-scoped and never environment-scoped, as a table of blast radius rather than a rule to memorize: DT_RUNPATH reaches one object, LD_LIBRARY_PATH reaches every descendant process forever, and a GLIBC_PRIVATE-coupled libc handed to the host loader kills /bin/sh before main (#401). - How to arm the AUR automatic triggers, including that the kill switch is unsetting a repository variable rather than reverting a commit. English and Chinese both, plus the changelog entry for 2026.8.10.1.
Checkpoint — 重新判定 Windows 阻塞点,并把跨仓库串行改成并行(
|
LD_LIBRARY_PATH |
|
|---|---|
| 已发布 mcpp | …/runtime:…/xim-x-glibc/2.39/lib64 |
| 本分支 | …/runtime |
决策收敛在新模块 src/platform/runtime_env_contract.cppm,是作用域不是条件:没有任何构建期判据能让一个继承变量对 mcpp 没启动、也看不见的进程变安全。
5. AUR:自动触发需要显式布防(D3)
schedule 每 6 小时跑一次且无条件 publish=true —— 合并本 PR 本身就足以让 mcpp 在 6 小时内无人值守地对 AUR 写入,而这条路径此前只做过 makepkg --verifysource dry-run。两个自动触发现在都只 plan+report,除非仓库变量 AUR_AUTOPUBLISH 精确等于 true(写错即 fail closed);workflow_dispatch 保留逐次开关,这正是第一次「有人盯着的」发布该走的路。契约测试直接执行 workflow 自己的判定 shell,而不是它的复述。
6. 其他
- D5:新增
209_runtime_verdict_never_reruns_green.sh—— 污染一条已存 verdict、不动任何源文件,下一次mcpp build必须仍然失败并打印存档诊断;mcpp self doctor必须从存档解释;重建后必须重新求值(是缓存,不是判决)。 - 覆盖盲区:身份/索引路由的 e2e 全部需要
gcc或fresh-sandbox,Windows 两者皆无 —— 路径语义真正不同的平台,恰好是从不断言它的平台。新增210_local_index_addressing_on_every_host.sh,无编译器、无沙箱、无网络,三平台都跑。 - 版本:xlings pin → 已发布的
2026.8.10.1(16 处 pin 由check_version_pins.sh机器校验);发布版本2026.8.9.1→2026.8.10.1(版本号是日期,评审期间日期变了;2026.8.9.1从未打过 tag)。自举 pin 保持已发布的2026.8.8.4。
本地验证
- 完整 C++ unit/integration:73/73,0 fail。
test_aur_reconcile+test_release_manifest:25/25。check_version_pins.sh、全部 workflow YAML 解析、git diff --check、隐私扫描:通过。- 新增/改动的 e2e 逐条通过:
00、12、42、43、44、09、27、32、62、162、208、209、210。 - 最新 HEAD 的完整 Linux e2e 全量跑正在进行,结果会单独回帖;在拿到终态之前不把任何一项记为通过。
提交
| Commit | 内容 |
|---|---|
3a6770d |
e2e fixture 路径改用 host 拼写(含 helper + lint + 40 处迁移) |
1c42c73 |
锁住 inherited index 的 lexical anchoring(符号链接 RED 已验证) |
4c0b7b7 |
裸名过渡期 |
afba6f0 |
#401:私有 libc 退出进程环境 |
1c3078e |
verdict 缓存不得靠重跑变绿 |
ead4933 |
AUR 自动触发需要布防 |
3bb2772 |
三平台本地索引寻址覆盖 |
d242922 |
发布状态:2026.8.10.1 / xlings 2026.8.10.1 |
70d2487 |
文档 |
Pinning to the current stable 2026.8.10.1 turned every Linux job red at
the same place: a COLD home cannot install xim:gcc@16.1.0 at all.
Downloading xim:glibc@2.44 …
integrity: cleaning incomplete install: …/xpkgs/xim-x-gcc/16.1.0
[gcc] failed: config hook failed
[xim:xpkg]: glibc payload not found, but gcc needs it to rewrite its
ELF interpreter away from the build machine's path.
install it first: xlings install xim:glibc@2.39
The version it installs and the version the hook asks for disagree, and
gcc.lua declares `xim:glibc@>=2.39` so resolving 2.44 is legal — the
failure is that the consumer's config hook cannot find the dependency
payload that was just fetched.
A/B on the same workflow, same runner image, both with a confirmed
cache miss, so this is not a long-standing cold-start bug that warm
caches were hiding:
2026.8.9.2 cold → gcc installs (run 31317627461)
2026.8.10.1 cold → the failure above (run 31335075557, 4/4 Linux jobs)
Nothing in mcpp can route around it: it is upstream install ordering or
store-root lookup, and it breaks every new machine, every cold CI cache
and every fresh install. Reported with the evidence as
openxlings/xlings#524; the pin moves once that ships.
The release version stays 2026.8.10.1 — it is a date, and this is a
different project's version that happens to share the string.
The design that drove this round of work, plus an appendix of outcomes written after the fact — including the two places reality diverged from the plan. D2 resolved as "proven, keep", but for a different reason than the commit it was defending claimed: not a Windows short-name alias, but that anchoring must not relocate an index out of the tree the workspace author addressed. D5's invariant turned out to already hold; it simply had no test. Two things arrived unplanned: #401, and the discovery that every identity/index-routing e2e was gated behind a capability Windows does not have — so the platform where path semantics differ was the one platform never asserting them. And main line C's bottleneck moved. The migration window took openxlings/xlings#521 off the critical path as intended, but pinning to the newest xlings put a harder one in its place: a cold home cannot install gcc at all (openxlings/xlings#524). Recorded with the A/B, because the lesson generalizes — "pin to latest" is an action that needs verifying, not a text substitution, and it only surfaced here because changing the pin also changed the CI cache key.
166 exists for mcpp#291 and had two halves. The negative half — a plain binary must not be handed the private glibc — is still exactly right and is unchanged. The positive half required the opposite in the presence of a dlopen-reachable dependency: the payload dir HAD to be on LD_LIBRARY_PATH, "because dlopen'd libraries do not consult the executable's RUNPATH". The guard was right to exist. It stopped anyone from "fixing" #291 by deleting the entry and quietly breaking dlopen. But it pinned the mechanism rather than the capability, and the mechanism's premise was false: a dlopen() performed by the executable does consult the executable's DT_RUNPATH, and the link model already puts the payload glibc there — the artifact's RUNPATH is byte-identical with and without the environment entry. So the entry bought nothing while reaching every descendant process, which is how it became mcpp#401. The capability it was protecting now lives in 208, which asserts the dlopen actually resolves. 166 keeps the rule it is named for and now applies it to both shapes, plus one new assertion: the project's own [runtime] library_dirs entry must still be there. Only the private libc is binary-scoped; dropping ordinary runtime dirs too would be a different regression that the negative assertion alone would not catch. Full local Linux e2e on this HEAD: 202 passed, 0 failed, 8 skipped.
Checkpoint — latest-head 全矩阵终态全绿(
|
| 项 | 结果 |
|---|---|
| 冷 sandbox bootstrap | PASS |
mcpp new(默认模板)/ --list-templates / 未知模板被拒 |
PASS |
冷工具链下 mcpp build / run / test |
PASS |
裸名迁移窗口(警告命名 compat.gtest) |
PASS |
mcpp add 把裸名迁成 [dev-dependencies.compat] |
PASS |
#401:mcpp run 下 /bin/sh 子进程存活 |
PASS |
| #401:私有 glibc 不在程序环境里 | PASS(LDLP=[<proj>/runtime]) |
| 精确 dotted 模板 selector | NOT_EXERCISED(本次 listing 里没有点分 selector) |
图形栈验收:mcpp 侧全绿,缺口在 xlings/xim
隔离 home 里 xlings install -y graphics 成功(NVIDIA 550.144.03,35 包),
GLFW + OpenGL 程序构建通过,mcpp why runtime 完整记录:
- requirement / provider / provenance(
index+compat@2026.08.08)/ link intent 全部正确 - SubOS 图形环境确实被应用:
__EGL_VENDOR_LIBRARY_DIRS、LIBGL_DRIVERS_PATH指向 SubOS - post-link 闭包校验 pass(含 12 个随产物部署的 X 库)
why runtime只读存档,不重新探测宿主
运行时仍拿不到 GLXFBConfig。定位:GLX vendor 库装在 SubOS 里
(<subos>/lib/libGLX_nvidia.so.0)但 payload 的 libGLX.so.0 在 dlopen 时够不到——
SubOS 只声明了 EGL vendor 目录,没有 GLX 侧的等价物。
而且不能用 LD_LIBRARY_PATH 兜:
$ LD_LIBRARY_PATH=<subos>/lib timeout 600 mcpp run
timeout: symbol lookup error: <subos>/lib/libc.so.6:
undefined symbol: __pointer_chk_guard, version GLIBC_PRIVATE
——#401 被手工复现了一次,也正好印证了 xim 自己在安装时打印的那条警告
(“Prefer RPATH on the consumer”)。按冻结的设计边界,driver/ICD 归 xlings/xim,
已带完整证据上报 openxlings/xlings#525。
mcpp 在这条链上没有待办:它消费的是规范化后的 provider 事实,没有探测 GPU/driver,
诊断出口也正确地指向 xlings doctor。
跨仓库
- openxlings/xlings#524:
2026.8.10.1冷装 gcc 失败(本 PR 因此把 pin 停在2026.8.9.2) - openxlings/xlings#525:GLX vendor 可达性
- openxlings/xlings#521:仍是正确的上游修复,已离开关键路径
按用户明确授权,接下来 squash + bypass 合入并发布 v2026.8.10.1。
概要
本 Draft PR 实现 #398 冻结的聚焦方案(包/模板身份、事务式项目创建、根本地运行时、图形栈 provenance、release desired state、
mcpp-binAUR 恢复),并在收尾阶段按.agents/docs/2026-08-10-pr400-completion-design.md的 D1–D5 全量补齐,同时纳入 #401。
核心产品决策:
[ns.]name[@version][:tname];省略ns严格等于mcpplibs;不引入--variant;唯一模板自动成为默认模板。compat.<name>与「不声明 namespace 的上游 descriptor」,但必须打印弃用警告、给出可粘贴的 manifest 片段,并把规范身份写入 lock/install/cache。2026.9移除。mcpp.toml中选择 xlings SubOS。SubOS 不传递,无 CLI override。mcpp-bin,且自动触发默认不发布,需显式设置仓库变量AUR_AUTOPUBLISH才布防。已实现
mcpp add自动迁移 manifestmcpp new:安全项目名、单次渲染、完整校验、rollback、跨平台 no-replace commitRuntimeSelection和不可变RuntimeBinding,build/run/test/fast path 共用同一快照__pointer_chk_guard,mcpp run 下子进程(/bin/sh)必死 #401:私有 glibc 退出进程环境,收敛为新模块src/platform/runtime_env_contract.cppm的作用域决策mcpp why runtime不重新探测 hostmcpp-release.json,最终公开 inventory 重取和 payload checksum 复算mcpp-bin-only AUR reconciler:event/schedule/manual、Arch vercmp、幂等/单调、checksum、fast-forward-only、有界恢复;自动触发需布防route:诊断host_pathhelper + lint,修掉 24 个文件里 40 处 shell 拼写路径2026.8.10.1、英文/中文用户和发布文档收尾阶段的三个判定(详见 checkpoint)
1. Windows E2E 2/2 的根因此前判错了
不是 workspace 索引继承(step 14),而是 step (15) 的 fixture 把 MSYS 路径
$TMP/...写进了mcpp.toml。原生mcpp.exe把开头的/读成「当前盘根相对」,索引落到C:\tmp\…。四条独立证据:退出码是 2(mcpp 自己的码经
set -e直传;step 14 被|| { …; exit 1; }包住只能是 1);step 14 的失败横幅不在日志里;失败前最后两条未捕获输出属于 step (5)/(12);step (15) 是本分支新增的,而 main 的 Windows E2E 是绿的。Wine 重放是假绿:Wine 把
Z:映射到/,\tmp\…落回真实/tmp/…。2.
ed4cf64的 anchoring 改动:已证明,保留改动前后失败文本逐字相同,说明它没修好任何东西。按 D2 做了真实 RED:换回
weakly_canonical会让unit/test_pm_index_route失败(71 passed, 1 failed)—— anchoring 必须把 index 留在作者声明的那棵树里,而经符号链接访问的 workspace 会被重定位。改动保留并由该用例锁住;同时把「断言路径拼写」换成能力断言。3. 裸名精确化是对已发布数据的破坏性变更
四个红 job 全是
ftxuiexact miss。本仓自己的mcpp.toml也被迫改才能自举,而索引里 34 个compat.*包与所有既有用户 manifest 都写裸名 —— 修 xlings 帮不到他们。因此加了迁移窗口(见上),xlings #521 不再在发布关键路径上。当前阻塞:openxlings/xlings#524
按要求把 xlings pin 提升到最新
2026.8.10.1后,4/4 Linux job 全红:冷 home 装不上xim:gcc@16.1.0—— 依赖解析下载 glibc 2.44,而 gcc 的 config hook 找不到该 payload。同一 workflow、同一 runner 镜像、两次都确认 cache miss 的 A/B:
2026.8.9.231317627461)2026.8.10.131335075557,4/4 Linux job)所以不是「一直坏、被热缓存掩盖」。已带证据上报 openxlings/xlings#524;mcpp 侧暂时把 pin 停在
2026.8.9.2,等修复发布后再提升(独立 commit)。验证证据
test_aur_reconcile+test_release_manifest:25/25check_version_pins.sh、全部 workflow YAML 解析、git diff --check、隐私扫描:通过00、09、12、27、32、42、43、44、62、162、208、209、210__pointer_chk_guard,mcpp run 下子进程(/bin/sh)必死 #401 实测对照(同一 fixture):已发布 mcppLDLP=[…/runtime:…/xim-x-glibc/2.39/lib64];本分支LDLP=[…/runtime]文档
尚未完成
v2026.8.10.1,验证所有平台资产、sidecar 和不可变 release manifestmcpp-bin:先手工 dry-run,再手工 publish 验证,最后才设AUR_AUTOPUBLISH__pointer_chk_guard,mcpp run 下子进程(/bin/sh)必死 #401;残留统一回写 汇总:2026-08-09 全量 issue 核验 —— 关闭说明、合并去向,以及 9 条新发现缺陷的收口 #397Closes #398, #401.
Related: #380, #392, #396, #397, mcpplibs/mcpp-index#197, openxlings/xlings#521, openxlings/xlings#524